Conversation
…orted with -fembed-bitcode`
|
@heroims please open the issue page |
heroims
added
good first issue
|
@alexcohn Hello, according to your modification, I have the following error reports. How to compile llvmgold.so。 ` [armeabi-v7a] StaticLibrary : libkooapk.a |
|
@androiddisk This build failure does not look related to the change in |
Andrei Matei reported a llvm11 core dump for his bpf program https://bugs.llvm.org/show_bug.cgi?id=48578 The core dump happens in LiveVariables analysis phase. heroims#4 0x00007fce54356bb0 __restore_rt heroims#5 0x00007fce4d51785e llvm::LiveVariables::HandleVirtRegUse(unsigned int, llvm::MachineBasicBlock*, llvm::MachineInstr&) heroims#6 0x00007fce4d519abe llvm::LiveVariables::runOnInstr(llvm::MachineInstr&, llvm::SmallVectorImpl<unsigned int>&) heroims#7 0x00007fce4d519ec6 llvm::LiveVariables::runOnBlock(llvm::MachineBasicBlock*, unsigned int) heroims#8 0x00007fce4d51a4bf llvm::LiveVariables::runOnMachineFunction(llvm::MachineFunction&) The bug can be reproduced with llvm12 and latest trunk as well. Futher analysis shows that there is a bug in BPF peephole TRUNC elimination optimization, which tries to remove unnecessary TRUNC operations (a <<= 32; a >>= 32). Specifically, the compiler did wrong transformation for the following patterns: %1 = LDW ... %2 = SLL_ri %1, 32 %3 = SRL_ri %2, 32 ... %3 ... %4 = SRA_ri %2, 32 ... %4 ... The current transformation did not check how many uses of %2 and did transformation like %1 = LDW ... ... %1 ... %4 = SRL_ri %2, 32 ... %4 ... and pseudo register %2 is used by not defined and caused LiveVariables analysis core dump. To fix the issue, when traversing back from SRL_ri to SLL_ri, check to ensure SLL_ri has only one use. Otherwise, don't do transformation. Differential Revision: https://reviews.llvm.org/D97792 (cherry picked from commit 51cdb780db3b9b46c783efcec672c4da272e9992)
3 participants
This is not a real Pull Request it has not been tested thoroughly enough, and may not be fit for everybody. I open it now as a way of discussion: what should be the right approach to resolve the limitation that was introduced by LLVM relatively recently.
This is the easiest way I found to work around
-mllvm is not supported with -fembed-bitcode.This didn't happen before, on llvm-9.0.1 (but that was not compatible with the modern Xcode).
I tried to simply remove the error check for
mllvmfromclang/lib/Driver/ToolChains/Clang.cpp, but this resulted in lots of suspicious warnings while compiling my iOS code, so I did not follow this path. Maybe, I did something wrong?